As is known in the arts, two primary modes of interaction include synchronous and asynchronous programming. In a synchronous function, a client calls the function and waits for the function to return after the function performs any required actions. In contrast, in an asynchronous function, a client calls the function but does not wait for the function to return. Rather, the client continues to execute and the asynchronous function “calls back” the client to return results when complete.
Certain types of clients require and/or are better-suited for one or the other type of programming (i.e., synchronous or asynchronous programming). For example, a program subject to operational time-constraints may require synchronous functionality. One example is a video processing service (such as one used by an embedded processor in a television) that must retrieve and process data within video refresh rates (e.g., 29.97 frames per second defined by the National Television System Committee). Such a client is best-suited for synchronous functionality (at least for the “real-time” response component) that operates within the limited time constraints.
Other types of clients require synchronous processing because they must obtain a result before execution can continue. For example, a geo-coding service may generate route directions from a starting location to a desired location by identifying a sequence of streets using a reverse lookup service on way points along the route. The geo-coding service must wait for the reverse-lookup service to return the next street (or a group of streets) in the sequence based upon the way points. Here, the geo-coding service requires a synchronous function call to the reverse-lookup service because it cannot continue to process the route without the identifying the next street.
In contrast, many other types of clients are better-suited for asynchronous services because they don't need or desire an immediate response to continue execution and/or they expect that a service or function will take some time to complete and/or must share a limited resource controlled by service with other clients. In one example, a client requests a batch process to execute on a server with the expectation that the batch process will take some time to finish. Here, the client sends the batch process to the server and does not wait for a response, in effect, placing the batch process in the background, while continuing with other tasks. For example, the client may continue to process user input. When the server completes the batch process, it returns the results to the client.
In another asynchronous service example, the client may be an image-editing program that enables different image editing functions on an image by issuing image-editing requests to an image server. For example, the image-editing program may issue a batch of functions to the image server, such as: “copy image A to image B”; “reduce size of image B”; “convert image B to format X”, and; “return image B.” The image server performs the batch functions and when complete calls back the image-editing program to return the results (i.e., image B). Such an example may apply to rendering systems in which rendering multiple images of a video clip requires minutes, hours, or days to complete.
As is also known in the art, web clients issue requests for content to a web server over the Internet. Although web client users desire to receive the content as soon as possible, they often must wait for the server to send the content, either because the server is busy handling other requests from other users or because of an overloaded network. If the server takes too long to respond, clients may “time-out” and stop waiting for the server, which may result in an error message on a client that the server did not respond. For example, web browsers (e.g. Internet Explorer™ manufactured by Microsoft Corporation of Redmond, Wash.) produce a time-out error message after a web server fails to respond to a request within a so-called “time-out limit” (e.g., 5 minutes, 60 seconds, 30 seconds, etc.).
A problem in the conventional art occurs when clients require and/or are better-suited for synchronous functions, but only asynchronous services exist to process the functions. In such cases, clients may terminate early, become unstable, or may not meet certain operational constraints or preferences.